BBS Toolkit/BBS Toolkit.iso/gt_power/gttutors.zip/GTTUTOR5.TXT

Text File | 1987-10-02 | 37KB | 679 lines

                       What is GT Netmail?

GT  Netmail  is  a function found in the  newest  release  of  GT
(tentatively  called  GT  Power 13.00) that  allows  a  regularly
scheduled and automatic exchange of messages between systems that
are  designated  as  being a part of the network  of  systems  so
engaged.  This exchange takes place without human intervention.

                            Concepts

A network of computers consists of any number of systems that may
be located anywhere so long as they are each able to connect with
each other via a modem.

Each  such  system,  if it is to be designated  as  part  of  the
network,  has a unique set of numbers assigned to it so that  any
other system that is also designated as part of that network  may
'know' of it and know how to communicate with it.  These  numbers
are called the 'Net/Node' for the system.

The  'Net'  part of the designator refers to the set  of  systems
that  are  presumed to be within local dialing  distance  of  all
others  bearing that same 'Net' designator.  For example, the  GT
Net  which is numbered 001 is the set of all systems  located  in
the greater Houston, Texas area.  Within that 'Net', each  system
is  given  a  unique 'Node' number.  Net  and  Node  numbers  are
separated  with  a slash for convenience.  Thus, 001/000  is  the
designation  of a system known as Node number zero on Net  number
001.

Net  numbers range from 001 to 999 while Node numbers range  from
000  to  999.   Unless  a system is designated  as  part  of  the
network, it is thought to have a Net/Node number of 000/000.

The National GT Network reserves all Net numbers from 001 through
899.   Net numbers from 900 through 999 may be used  for  private
networks  or  other  Local  networks that are  NOT  part  of  the
National GT Network.

Node  number  000 is significant only in that  by  convention  it
refers  to  the  Local  Net Coordinator.   This  person  has  the
responsibility  of assigning all Node numbers within his/her  Net
and  for  assuring the security of those Nodes (more  about  that
later).

Net  numbers  are assigned by the  National  Network  Coordinator
(James Davis at this time).

In  order for a message to enter the stream of messages that  are
automatically  routed  from Net/Node to Net/Node by  the  system,
those  messages  must be created with  a  destination  (Net/Node)
along  with  an addressee.  This is only possible  at  this  time
within  message  areas  that  are  specifically  established  for
Netmail.

Within  your  GTMDIR.BBS file, which is located  within  your  GT
directory,  is a list of all message bases known to your  system.
A typical entry contains an authorization level, a pathname,  and
a  brief  description of that message base.  You may  specify  as
many  Netmail message bases as you wish.  In order to do  so  all
that is necessary is that you add a tilde (~) to the beginning of
the pathname for that message base in this file.  For example,

(GTMDIR.BBS contents:)

B   C:\GT\BETA     Beta test message base.
=C  C:\GT\PRIVATE  Private message base.
*D ~C:\GT\NETMAIL  Netmail CONFERENCE - restricted access.
F   C:\GT\GENERAL  General public message base.

Line  one shows a message base that requires at least  an  access
level of 'B' in order to gain access.

Line  two  shows a private message base available only  to  those
users that have access level 'C' assigned to them.

Line  three shows a conference message base.  This means that  so
long as the user has at least an access level of 'D' he/she  will
be able to see that the message base exists, but until the  Sysop
changes the BAN flag that is set in the user record  (GTMAIL.CTL)
when  the  user  first tries to access  this  base  (applies  for
access),  the  user may not actually get into the  message  area.
Also,  because the pathname starts with a tilde (~), the  message
base  is  used  to send and receive  messages  over  the  Netmail
network.

Of  course,  line four shows a message base that anyone  with  at
least an access level of 'F' may enter.

There is actually one additional  control symbol  that the  Sysop |
may use with a  Netmail message base entry  in  GTMDIR.BBS; it is |
the carrot  (^)  and it indicates that  NO PRIVATE  messages  are |
allowed by any user,  even if  those  users have  private message |
capability.   The symbol  is placed  in front of  the  tilde  (~) |
in the GTMDIR entry for that message base.  For those of you that |
wish to have more than one message base,  and to  prevent private |
messages in  ALL Netmail directories,  you may use this symbol in |
your  GT.CNF  file  (via Alt-I)  entry that  specifies  the  main |
message base.                                                     |

When a user has been authorized to enter into the Netmail message
base he may create and read messages just as in the other message
areas (and with the same restrictions - namely, Private mail only
if  authorized).  When entering a message in this area,  however,
when  he is asked to enter the 'To:' name, and does so,  he  will
then be asked to enter the Net/Node number where that message  is
to be delivered.  If the user does not know the correct  Net/Node
number he is given the ability to List all Net/Nodes known to the
system.   Further,  he  may  have the system  scan  the  list  of
Net/Nodes  looking  for  either a part of the  BBS  name  or  the
addressee's  name.   In any event, the user must  input  a  valid
Net/Node  number  in order to proceed.   (Incidentally,  you  may
specify  only the significant digits in a Net/Node  number.   ie,
1/0 is the same as 001/000).

Recall that all nodes with the same Net number are presumed to be
local  calls  from  any  other Node in that  Net.   Thus,  it  is
presumed  that  these calls do not cost anything to  place.   For
that reason, if the user specifies a Net/Node that is 'local' and
it  is  found that that Net/Node exists, no further  checking  is
performed.  However, if the Net is other than the one he is using
as  he prepares the message, then because the call  will  involve
(by  assumption) long distance charges to the Sysop, a method  of
cost  control  has been implemented that may deny  the  user  the
right  to  create  the message.  That is, if the  user  has  been
assigned  some  number  of CREDITS (units, not  dollars),  he  is
allowed  to create the message for the 'out-of-net'  destination.
Otherwise he is not allowed to do so.

There  is  a GTMAIL.CTL file associated with each  message  base.
The  message  base that is called the 'default message  base'  is
where  the main user file (GTMAIL.CTL) exists.  It is  this  file
that  is used to determine if a user is to be allowed  access  to
the system at time of logon.  This main message base user file is
NOT the one in which CREDITS are assigned relative to the use  of
Netmail.   In order to provide a user with a CREDIT balance,  you
must  use  GTCTL and change to the Netmail message  base.   Then,
using  GTCTL's 'Update User' function (Option 4), you may  change
the user's CREDIT balance.

Scheduled  'events' are a function of GT that are Sysop  defined.
That is, there is a new file called SCHEDULE.BBS that is  located
in the GT directory.  Besides certain control information,  there
is  an entry for each 'event' that the Sysop wishes GT to  become
aware of and to cause to happen at a specified time.  An  'event'
is merely a program or a batch file name.

For example, the following entry might be used to specify that an
event called 'MAIL' is to occur at 4:00 a.m.:
           04:00-04:15  MAIL  (start range)

'MAIL',  of  course, is either the name of a program or  a  batch
that  DOS can find via its PATH.  Let us suppose that it  is  the
name of a batch file (MAIL.BAT).

This batch file would contain DOS commands such as the following:
          MBAGGER
          MDRIVER XXXX-YYYY sss eee /D5                           |
          MDIST

Thus,  at  4:00 a.m. GT would cease all  communications  activity
(gracefully,  and in fact, about five minutes earlier)  and  then
Shell  to  the MAIL batch file.  DOS would, in turn,  invoke  the
MBAGGER  program  and  when that completed it  would  invoke  the
MDRIVER program, then the MDIST program.  When that third program
was finished, DOS would return to the scheduler program within GT
and GT would resume normal communications.

This is exactly how you should setup for Netmail.  Now it is time
to discuss the parts of Netmail to make it clearer as to what  is
happening.

There  are several new directories that must exist on  the  drive
that contains your GT programs.  You do not have to create  these
directories  as  when they are needed the Netmail  programs  will
create them automatically if they do not exist.

The  first  is  called  \MAILWORK.  This  directory  is  used  as
workspace for the various Netmail programs and normally  contains
nothing in it.

The  next  two are:  \MAILOUT and \MAILIN.  These  are  used  for
temporarily storing messages that have been 'bagged' to get ready
for delivery to another Net/Node or which have been received from
other  Net/Nodes prior to being 'un-bagged' and distributed to  a
message  base,  respectively.   Bagging a  message  merely  means
ARChiving  it into an ARC file with a name that contains  routing
information along with all other messages to be delivered to that
same destination.

Please  note,  IT IS ASSUMED THAT YOU HAVE A COPY  OF  PKARC  AND
PKXARC SOMEWHERE IN THE DOS PATH FOR NETMAIL TO WORK!!!!

                             MBAGGER

This is a standalone program that finds all Netmail message areas
that  you  have  defined (by reading  your  GTMDIR.BBS  file  and
looking  for  those tildes).  It then looks at  each  message  in
those  message  bases looking for those that have  not  yet  been
'MAILED'.  A message has been 'MAILED' as a result of the actions
of  the  MBAGGER program, not because it has actually  been  sent
over a telephone line.

If the message is destined for your own system (has YOUR Net/Node
as a destination), then MBAGGER marks it MAILED,  'bags' it,  and
moves that bag to your \MAILIN directory.  If it is for any other
Net/Node  then this program  creates or updates  an  ARChive file
with a  name  that  insures  that it will be  sent to the  proper
Net/Node and  places all  messages destined to that same Net/Node
into  this  file  (the 'bag') before  placing  the  bag into your
\MAILOUT directory.

When all messages have been 'bagged' and marked 'MAILED', MBAGGER
is complete and returns control to the batch file processor.

                             MDRIVER

This  is the heart of the Netmail system.  This program  is  told
the start and end time of the Netmail run  (normally an hour) and
it  will wait in memory until the start time before beginning  to
do  anything.  When the start time is reached, MDRIVER  wakes  up
and  begins alternating between listening for the phone  to  ring
and making outgoing calls.

Please note,  start time  and  end time  (sss and eee)  is  to be
specified in pseudo military time. That is, using a 24 hour clock
and  using  24:00  to  mean  midnight  rather  than 00:00.  Whole
numbers may be used (ie, 23 is the same as 23:00).

In  an effort to insure that all nodes do not get into synch  and
try  calling each  other at precisely the same time  as the other
nodes  are  trying, there is a  random  time  duration  generator
within  this  program.   Thus, you will see  that  some  variable
number  of seconds (usually between 1 and 30) will lapse  between
attempts by your system to make a call out.

Should your  phone ring, the program will answer it  and  try  to
determine who has called.  If it is a human or a system operating
in terminal mode (still considered a human) then the caller  will
be  told that your system is in the middle of a Netmail  run  and
asked  to call back later before the connection is  broken.   If,
and  only  if, it is a Netmail Node that is  calling,  then  this
program  will insure it is a valid Net/Node  (authorized)  before
progressing.  If not, it will disconnect and await the next call.
If  it is a valid Net/Node Netmail caller, then the program  will
accept mail from it (putting the received bags of mail into  your
\MAILIN  directory).  It may also then deliver mail you  have  on
your  system with the caller's Net/Node as a destination at  that
time.

Recall  that if the Net number is the same as your own, it  is  a
local  call.  In that case, the calling system will be forced  to
accept  delivery of mail destined for it as there is presumed  to
be  no extra costs involved.  Interestingly, if the call came  in
via  PC-Pursuit, it is also assumed that there is  no  additional
cost and the caller will be required to accept delivery from you.
In any other situation, your system will not force delivery  upon
the caller.

When  all  messages have been sent and/or received,  the  session
will  end and the program will once again begin  the  alternating
between listening for the phone to ring and making calls.  (There
is also the possibility that the caller may ask for a file to  be
sent  to him or to attach a file to a message.  These  situations
are discussed later).

Your  system will place calls to all Net/Nodes that have Bags  of
mail  to  be  delivered to them.  (If you wish to place a call to |
a Net/Node,  even if you do not have any  mail to deliver to that |
Net/Node,  you may  force the system  to do so  by  including  an |
OUTBOUND NODE entry  in your  ROUTING INSTRUCTIONS.)  These calls |
are  simply the reverse of the receipt of a call.

When  all bags that are to be sent have been forwarded  to  their
destinations,  or if the mail hour end time occurs, this  program
terminates and returns control to the batch processor.

One of the additional functions of the MDRIVER program is to help |
the sysop avoid 'stale mail' collecting in his MAILOUT directory. |
This is done via the inclusion of a command line parameter on the |
MDRIVER command line.  The format of this 'switch' is: /Dxx where |
xx is the number of days a mailbag will be allowed to age  before |
it is removed from the MAILOUT directory.   In a very real sense, |
such a mailbag contains dead-letters.   Thus, MDRIVER renames the |
bag by replacing the first letter (B) with an 'X'  and, if it was |
originated on your system,  moving  the  bag to a subdirectory on |
your system  called  \MAILOUT\DEADLTR.  If the bag  originated on |
some other system,  then the system  will create a message to the |
sysop of the originating Net/Node  telling him you were unable to |
deliver the bag and the bag will be File Attached to it.          |

                              MDIST

This program gets control and looks into the \MAILIN directory to
see if any mail has been delivered to you.  If so, the mail  bags
are unARCed and the resulting messages are placed into the  first
Netmail  message  area.   (In  a  future  release  we  may   have
implemented  a method for distributing to various message  bases,
but not at this time.

Note that all messages that pass through the Netmail system  have
the ORIGIN Net/Node number and BBS name suffixed to them so  that
the recipients of them will know where they came from.

When this program is completed control returns back to the  batch
processor which, in this example, will then return control to the
GT  scheduler and cause GT to return to the mode it was in  prior
to the event.

                         File Transfers

Netmail  uses  two  'dot  commands' similar  to  those  found  in
WordStar to indicate that a file is attached or requested.  These
dot  commands are '.FA' and '.FR' respectively.  The period  MUST
be  found in column one of any line of the message text, and  the
FA or FR are to immediately follow (without intervening  blanks).
Also, following one or more blanks, there is to be a file name.

Thus, if a message contained the following line in it:

.FR NODELIST.BBS

Then the recipient of that message would understand that it is to
look  for  a file called 'NODELIST.BBS' in a  directory  that  is
specifically set up for the purpose (\MAILOUT\FILEOUT) and if  it
finds that file it is to send it to the caller (via Megalink).    |

It is EXTREMELY  important  for  you  to  recognize  that  a File |
Request  (.FR)  requests  an  immediate  file  transfer  of   the |
requested file rather than just requesting that a message be sent |
back to the originator that contains that file.  Consider that as |
a significant difference,  File Requests  are not simply  one-way |
transactions.  One-way transactions allow Netmail to be effective |
over PCP, and, as a result, provides for (in conjunction with the |
implementation of Local and Continental Hubs)  cost free  traffic |
from coast to coast.  Let me be even more specific,  ALL messages |
that contain a File Request (.FR) will be sent  DIRECT  from your |
Net/Node to the destination Net/Node (WITHOUT using HUBS).  Thus, |
if you are in New Your and request a file from a node in Florida, |
the MDRIVER program will call Florida (ie, a Long Distance call). |
Thus,  when they connect,  the File Request can be honored.   For |
this reason  we have  provided you  the ability  to prevent  your |
users from using either .FA or .FR capabilities.                  |

Similarly,  if the '.FR' had been a '.FA', then the  caller  will
send  a file to the receiver (host) and it will be placed into  a
directory called \MAILIN\FILEIN  when received.   The method used |
here is quite different than in the case of File Requests.   File |
Attaches are detected by the MBAGGER program which looks into the |
\MAILOUT\FILEOUT directory on your system for the specified file. |
Finding it,  MBAGGER then archives that file  (using PKARC)  into |
the same mailbag as the message which contains the .FA message.   |

It  is expected that the SYSOP will control access to these  file
transfer  functions  via new authorizations in  the  GTPASSWD.BBS
file.  'FR' is the authorization code for use within the password |
file that allows  a user with that authorization  to use the  .FA |
and .FR commands.                                                 |

                            Security

A  Prime  objective in the design of the GT Netmail  function  is
security.  It would be a disaster, for example, if any user of GT
should  'pretend'  to be a valid Net/Node and  call  other  valid
Net/Nodes  requesting mail to be delivered.  For this  reason  we
have  developed a concept called the CRC that must be  used  with
the  MDRIVER  command.  Without a valid CRC, the MDRIVER  is  not
capable of establishing a Netmail session.

The  CRC codes are assigned by the National Network  Coordinator.
Like passwords, the CRC code for a Net/Node is CONFIDENTIAL!!!!!!

In the example MDRIVER command shown above, the XXXX-YYYY is  the
CRC  code assigned for the node that is running the  code.   (The
'sss' and 'eee' are start time and end time of the session).

                       Additional Control

There are two more files associated with GT Netmail;  ROUTING.BBS
and NODELIST.BBS.  Like the others, these must be located in  the
GT directory.

                          NODELIST.BBS

This file contains the valid Net/Nodes for the network along with
telephone numbers, baud rates, City, BBS name and Sysop name.  It
is usually provided by the Network Coordinator.  It is  necessary
to be running with the most current NODELIST.BBS at all times!!

                           ROUTING.BBS

This file  contains  as many  as  seven  'sections' at this time, |
though there may be others added over time.   The first  is  used |
to  define  the  PC-Pursuit numbers so that your system will  use |
PCP for those  Net/Nodes  where it is appropriate.   The documen- |
tation which accompanies your Netmail programs contains a complete
example  of this section of the ROUTING.BBS file.  Note that  you
need  only  include  those PCP numbers that are a  part  of  your
network.  Also please note that the city name in the NODELIST.BBS
must   match  identically  those  listed  in  this   section   of
ROUTING.BBS in order to recognize that a call is to be placed via
PCP.   Note that each section of the  ROUTING.BBS file must start |
with the section name  (in this case, 'PURSUIT'),  and end with a |
line that contains the single word 'END'.                         |

The  second  section  of this file is called  the  INBOUND  NODES
section.  This is used in order to tell your MDRIVER program that
it  is  NOT  to  place calls to  the  Net/Nodes  specified.   For
example,  some Net/Nodes have access to PCP and, thus,  they  may
call  you without additional cost.  These same Net/Nodes may  not
be  Pursuitable.   Thus, you mark them as INBOUND NODES  and  you
will  receive calls from them but not place calls.   And,  recall
that  if  they are via PCP your mail to them will be forced  upon
them as there is no additional cost to the caller to do so.

The entries in this section are in the following format:          |
              Net/Node-Node      where Net is the Net number  and |
Node-Node is a range of Node numbers (even the same one).

The next section,  like all of them,  is optional  and  is  named |
'LONG DISTANCE'.   It is used to  override the default rules used |
by  MDRIVER  to  determine if a number is local or long distance. |
(Default has it that  all nodes  on the same Net are local.  That |
is, any number that has an area code that matches the one {or more}
specified in your  SCHEDULER.BBS  file is assumed to be local and |
will result in a dialing string like this: ATDTxxx-xxxx|).  There |
are times,  however,  when a node may have the same area code but |
still be considered long distance by your local telephone company.|
In such a case  your dialing string  would have to be constructed |
like this:   ATDT1,xxx-xxx|  so we have provided this  section to |
allow you to specify which nodes those are.   The format of  each |
entry in this section  is identical to that of the  INBOUND NODES |
section;  NET/Node-Node.                                          |

Next, there is a section called 'OUTBOUND NODES'.   This is used, |
to specify those Nodes that are to be called during each  Netmail |
session at least once, whether there are any mailbags to be  sent |
or not.  Note, in this section only, a range of nodes is not used |
along with the Net number.   That is,  valid entries contain only |
only the specific Net/Node desired.                               |

Another section is called  'PREFIXES'.   Within this section  you |
may  tell  MDRIVER  if you wish  it to prepend prefixes and/or to |
append suffixes to the dialing strings it creates.  There are two |
kinds of  numbers  as far as MDRIVER is concerned; Local and Long |
Distant.  Each may have prefixes and/or suffixes and these may be |
different  as  between  the  two  types  of numbers.  Within this |
section,  you  specify  LOCAL  prefixes  with the keyword 'LOCAL' |
followed  immediately  with  the  symbols  for  the  prefixes and |
suffixes desired enclosed in parenthese.  The symbols are the same|
as used in your  GT.CNF  file and MDRIVER extracts from that file |
what the symbols mean.                                            |

For example:   LOCAL(-)   or   LOCAL(*,+)   or  LOCAL(,!)         |

The first example shows MDRIVER being told to add a prefix to all |
local calls.   The second example shows it being told to add both |
a  prefix  and a  suffix  to  all local calls.  The third example |
shows it being instructed to add only a suffix to all local calls.|
Similarly, you may control the dialing string for all long distance
calls.  The keyword in that case is 'DISTANT'.                    |

Note, if you specify a prefix for long distance calls then MDRIVER|
WILL NOT automatically insert a leading '1,' in front of the area |
code.  It becomes your responsibility to do so.                   |

ROUTING INSTRUCTIONS  is the next  section.   It is  conceptually |
rather easy to understand,  but is  probably the  single greatest |
source of trouble to new users of NetMail.    The purpose of this |
section is to tell MDRIVER where to send mailbags that it finds in|
your MAILOUT directory that are not destined to your own system.  |

Further, it also specifies how your system will respond if asked  |
by another Netmail system to accept mailbags for destinations that|
are not yours (this is called mail forwarding).                   |

In the  simplest  of  cases,  you  will not have anything in this |
section ofyour ROUTING.BBS file,  but that would prevent you from |
benefiting from one of the best features of NetMail;  the ability |
to  send and receive  messages  from  coast to coast without cost |
- utilizing Hubs.

A Hub is merely a GT Netmail system that has been established and |
setup in such a way that it will accept mail for other Net/Nodes. |
At the  present  time,  there  are  two  kinds of Hubs: Local and |
Continental.  A Local Hub is established in each Net (usually the |
Hub coordinator's system).   These Hubs  accept mail for any Node |
within the Hub and will forward those mailbags to the destinations|
desired.  Thus, any node can send all mail to all nodes in the Net|
by  placing  only  one  call (to  the  Local Hub) and sending ALL |
outbound mail to it.  The Hub, in turn, will place all local calls|
necessary to deliver that mail.                                   |

The Continental Hubs  are  established as clearing houses for the |
Local Hubs.   These Continental Hubs accept Mail for ANY Net/Node |
on the Network.  Local Hubs may call a Continental Hub and forward|
ALL mail  destined out of  their own Net.   The Continentala Hubs |
have been established in such a way as to have certain Local Hubs |
assigned to them.   Thus,  when a Local Hub calls its Continental |
Hub it can receive all mail  destined to that Net as well as make |
deliveries.   Continental Hubs  will forward  (or arrange to have |
forwarded)  all  mail  that  belongs  to  other  Continental Hubs |
automatically.  Thus, a Local Hub can 'deliver' ALL of its out-of-|
net mail with one phone call to its assigned Continental Hub.     |

All  of  the  above  explains  why  we  have included the ROUTING |
INSTRUCTIONS section.   There are two kinds of entries within it. |
The  first  utilizes the keyword  'FORWARD' while the second uses |
'ACCEPT'.  The FORWARD keyword is used primarily by non-Hub Nodes.|
These tell the MDRIVER program where to send all mailbags.  These |
entries may utilize re-direction or not.   Re-direction is merely |
an alternate address to which a mailbag will be sent  RATHER THAN |
the actual destination.   Specifically,  in the case of a non-Hub |
node, every Net/Node address that the sysop of that system wishes |
to communicate with  (usually the entire network),  should have a |
FORWARD entry that tells the MDRIVER to re-direct those  mailbags |
to the  Local Net Hub rather than directly to their destinations. |
In this way,  the non-Hub nodes can 'deliver' all mail with but a |
single phone call (a local one) to their Local Net Hub. Following |
is a set of  FORWARD entries  that shows this for a  non-Hub node |
identified  as  004/009 where the Local Net Hub has an address of |
004/000:                                                          |

ROUTING INSTRUCTIONS                                              |
  FORWARD 001/000-999 -> 004/000                                  |
  FORWARD 002/000-999 -> 004/000                                  |
  FORWARD 003/000-999 -> 004/000                                  |
  FORWARD 004/000-000                                             |
  FORWARD 004/001-008 -> 004/000                                  |
  FORWARD 004/010-999 -> 004/000                                  |
  FORWARD 005/000-999 -> 004/000                                  |
  etc.                                                            |
END                                                               |

The first three lines tell  MDRIVER  that if it should attempt to |
deliver mail for any node within  Nets 001 through 003, it should |
re-direct delivery to the Local Net Hub (004/000).  Line four says|
that  mail  addressed  to 004/000 is to be sent directly (without |
re-direction)  to that Net/Node.   The fifth line says re-directs |
mail destined for nodes  001 through 008 of Net  004 to the Local |
Net Hub.   004/009 needs no  FORWARD nor re-direction because the |
messages to that  net/node are already  at their  destination and |
MDRIVER will never see them.   The sixth line  re-directs all the |
rest of the mail for Net 004 to the Local Net Hub.                |

What,  then,  does an  ACCEPT entry  do that is  different from a |
FORWARD entry?   Only one thing: It allows your MDRIVER to ACCEPT |
re-directed mail for those  net/nodes and to show what to do with |
it.  That is, if you are accepting delivery of mail for some other|
net/node  (you are acting as a Hub),  then  you must  specify via |
ACCEPT  statements  rather than  FORWARD statements that you will |
allow receipt of such mail.   In  all  other  aspects the  ACCEPT |
statement is identical to the FORWARD statement.                  |

One GOLDEN RULE to remember about these entries: The same address |
must  NOT  appear  on  both  sides  of  a  re-direction  command. |
For example,  ACCEPT  004/000-999 -> 004/000  is in error,  since |
004/000  is  found on both sides of the re-direction symbol (->). |
Why?   Well,  when MDRIVER attempts to re-direct mail for 004/000 |
to net/node 004/000, then it will do so with a forwarding request |
of the receiving system.  This means that the receiving system is |
to accept the delivery of mailbags and place them into its MAILOUT|
directory  rather than its MAILIN directory.   Since it goes into |
the  MAILOUT directory,  when the session completes,  MDRIVER re- |
organizes itself  so that it can attempt to make  delivery of all |
mailbags in its MAILOUT area.  Recall that MBAGGER shortcircuited |
this step for  all mail destined for the  system they are already |
on.   MDRIVER is not designed to handle bags of mail destined for |
itself.   Without the re-direction symbol,  MDRIVER sends mail to |
the destination directly and the receiving system puts it into its|
MAILIN directory.                                                 |

The  last  currently  defined  section  of  ROUTING.BBS is called |
'PICKUP OVERRIDES'.   Here,  we  have  provided  a method for the |
sysop to override  MDRIVERS cost control functions.   Local calls |
and those that are made over PC-Pursuit will always first deliver |
the mail that they have to deliver,  then they will automatically |
request delivery of all mail destined (or forwarded) to it. This, |
because there is  no extra cost to the caller  if the duration of |
the call is slightly extended.   Long distance calls made without |
the benefit of PCP, however, do not automatically request delivery|
of all mail.   Thus,  only  the  purpose of that call (sending of |
mail) is attempted during such a session.   If, however, you want |
mail  to  be  delivered  during  such a call,  you would use this |
section to so specify.   The format of such an entry is identical |
to that used  LONG DISTANCE and  INBOUND NODES sections described |
above  (ranges included).   Note that specifying a  Net/Node here |
will  NOT  automatically  result  in  a  call  to  the  specified |
Net/Node(s)  unless  there is  mail to be sent to that node.   To |
force a call, you must use the OUTBOUND NODES section.            |


                        Setting it all up

Assuming  you are running the latest version of GT,  these  steps
will get you set for participation on the Netmail network:

1)   Obtain  a Net/Node number from your  Local  Net  Coordinator
along with the CRC code to be used with it.

2)   Create  a  Netmail message base  via  modification  of  your
GTMDIR.BBS file (The tilde character before the pathname).

3)  Create a SCHEDULE.BBS file.  It should contain the  following
lines:
     NET=xxx
     NODE=yyy
     AREA=zzz         (may contain multiple #'s.  ie, =713,510)   |
     NAME=BBS name
     CITY=your city (same spelling as in PCP list in ROUTING.BBS)
     04:00-04:15 MAIL  (Will start anytime in range 4:00-4:15)

Obviously,  the  event shown scheduled for 04:00  should  be  the
actual time of the event as specified by your Net Coordinator.

4)  Create  the MAIL.BAT file:
     MBAGGER
     MDRIVER XXXX-YYYY 4 5 /D10    (XXXX-YYYY being the CRC code) |
     MDIST

5)  Create the ROUTING.BBS file as described above.

6)  Copy the NODELIST.BBS file into your GT directory.

7)  TEST IT - TEST IT - TEST IT


                         GOLDEN RULES!!!

If you have a Net/Node number assigned then you must follow these
two simple rules:

1)  Your system MUST be running Netmail during the same hours  as
everyone else on the Network!

2)   If for any reason your system is not running Netmail  during
those hours, YOU MUST NOT ANSWER THE PHONE DURING THOSE HOURS!!!!

                      The Immediate Future

The volume of Netmail traffic will increase quite rapidly as we add |
new Nets and Nodes to the Network.  We have already seen during the |
testing  period  preceeding the formal release of Netmail that each |
Hub  can handle upwards of 100 mailbag transfers per hour, assuming |
faithful  adhearance to the concept that  only  Local Net Hubs call |
Continental Hubs  and that there are a resulting  multiple mailbags |
per  call  that  increased  the efficiency of the sessions.   Soon, |
however, we will surpass that  capability  and  we  will  be forced |
to add more Continental Hubs.  At the time of the release of Netmail|
there were only  two Continental Hubs.   Paul Meiner's has a second |
system  that  will  become  the  third  Continental Hub immediately |
(001/003).   And a fourth will come on-line  as necessary.   In the |
very  near  future  we  will  add  one  more  level of  Hubs to the |
architecture:  the Regional Hub.  It is expected that there will be |
an  Eastern and a  Western  Regional Hub in the near future.  These |
Hubs  will  accept  mail  from  any  Local  Net  Hub  within  their |
geographical  area of interest and forward  (re-direct) mail to THE |
Continental Hub  they are assigned to,  or to Local Net Hubs within |
their areas, or to the other Regional Hub.  What does not change is |
that these Regional Hubs must place at least  one call per Netmail- |
day  to  their  designated  Continental Hubs in order to insure the |
receipt  mail from other places around the country.   As plans firm |
up for these Regional Hubs we will have much greater flexibility in |
routing  mail.   This  will  be  facilitated with new capability in |
MDRIVER  that  will allow the user to specify  ALTERNATE ROUTING of |
mail  should  it  not  be  able  to  deliver  mail via the route of |
preference.                                                         |

In a very real sense,  the dynamics of Netmail will determine where |
we go from here  in terms of  design and  implementation.   What is |
certain, however, is that users of Netmail are to follow the design |
faithfully in order that it be as efficient as possible.  Providing |
coast to coast  mail capability  without cost to the users was done |
with  an  architecture  in  mind.   To not use that architecture as |
designed will damage the success of the effort.                     |

Enjoy the  facility and please  send any feedback you would like us |
to consider.                                                        |